QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/tcp/940021.txt

Internet Message Format | 1994-11-13 | 18KB

Date: Tue, 25 Jan 94 04:30:08 PST
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #21
To: tcp-group-digest


TCP-Group Digest            Tue, 25 Jan 94       Volume 94 : Issue   21

Today's Topics:
            AMPR and Fully-Qualified Domain Names (2 msgs)
                   e-mail address of PA3EFU/VK3CEX
                           GPIB and packet
  help understanding the division point of protocol vs app (2 msgs)
             ping-pong convers for Linux FTP site gone ?
                TCP MSS and TCP WIN settings (2 msgs)
                          TNC3s information
                    Unclear about MTU in attach...

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 24 Jan 94 09:21 PST
From: [e-mail] (Bruce Perens)
Subject: AMPR and Fully-Qualified Domain Names
To: [e-mail]

The SMTP servers of our local NOS systems identify themselves using
their host names without the ampr.org extension. Some of them refuse to
accept mail with the ampr.org extension. For instance, my neighbor
Dennis runs PA0GRI NOS 2.something. I tried a few addresses on his SMTP
server and got this response:

    RCPT TO:<dennis>                                Works
    RCPT TO:<dennis@ccwest>                         No such address.
    RCPT TO:<dennis@ccwest.n6ng>                    Works
    RCPT TO:<[e-mail]>           No such address.

This system is configured as hostname "ccwest.n6ng", domainname "ampr.org".
I'm somewhat confused regarding the use of "ccwest.n6ng" as a host
name since I would read n6ng as a sub-domain in this example.
This last address above is very distressing, as that is the one I would like
to use. Also distressing is the fact that incoming SMTP connections
from AMPR identify themselves with their host names alone without the
ampr.org extension. I have to run a hack using the internet address to
determine if I should tack ampr.org onto those addresses.

My local address coordinator says Brian Kantor told him it _should_ be
this way, and that an internet mail gateway must add ampr.org to mail
in the ampr->internet direction and strip off ampr.org in the other
direction. He explained that this was due to the lack of domain name
service on AMPR.

So, is the problem a continuing lack of domain name service, is
it simply broken software, or something else? Can anyone supply a good
explanation?

    Thanks

    Bruce Perens AB6YM

--
Bruce Perens AB6YM [e-mail] 510-215-3502

------------------------------

Date: Mon, 24 Jan 1994 18:52:30 -0800
From: [e-mail] (Brian Kantor)
Subject: AMPR and Fully-Qualified Domain Names
To: [e-mail]

In article <[e-mail]> Bruce wrote:
1>    RCPT TO:<dennis>                                Works
2>    RCPT TO:<dennis@ccwest>                         No such address.
3>    RCPT TO:<dennis@ccwest.n6ng>                    Works
4>    RCPT TO:<[e-mail]>           No such address.

ALL of the above RCPT-TO addresses would work if CCWEST.N6NG.AMPR.ORG
were running a properly-configured and reasonably flexible mailer.
However, it is arguably true (RFC1123) that only the LAST of these,
which is the only address that includes a Fully-Qualified Domain Name,
is 'correct'.

It's conceptually simple: hosts sending mail outside of a domain must
be sure that the FQDN is in the address of the mail.  Early documents
suggested that common parts of the FQDN could be omitted.  That proved
to be such a bag of worms that nearly everyone agrees that you should
always include the full hostname.

In this case, 'n6ng.ampr.org' is the domain enclosing the host 'ccwest'
- although because we don't delegate domains in the ampr.org domain, it
could also be viewed as a complex hostname of 'ccwest.n6ng', which is
probably why #3 above works.

There are some tightly-controlled domains where it might be permissable
to bend the "use FQDNs everywhere" rule slightly by not using any
qualified hostnames at all internally, but making sure that mail always
passes through gateways between the "internal" network and the outside
world that do the proper qualification.

In the AMPR world, I suspect that we can't do that.  Our domain is
not tightly-controlled, there are a lot of broken and half-assed mailers
out there, and the "internet-mailer-competency" of many host operators
is hardly assured.

Best to do FQDN whenever we can.
    - Brian

------------------------------

Date: Mon, 24 Jan 1994 15:20:29 +0100
From: [e-mail] (Adam van Gaalen PA2AGA)
Subject: e-mail address of PA3EFU/VK3CEX
To: [e-mail]


Hello all,

Sorry to bother all of you, but I saw a note from Jan Jaeger PA3EFU/VK3CEX in
tcp-group digest number 20... It has been long since Jan and I talked together
so I thought I might try to catch up over e-mail...

The only thing I need now is his internet-address...  PSE HELP!

73 de
Adam van Gaalen ([e-mail])

------------------------------

Date: Mon, 24 Jan 94 18:40:06 GMT
From: Jan Schiefer <[e-mail]>
Subject: GPIB and packet
To: [e-mail]

Some days ago I suggested the use of GPIB/HPIB/IEC625/IEEE488 for use with
packet radio and asked for feedback. I'd like to summarize the replys I got.

The overall perception was that it would not be wise to use an interface
that is not available on Joe Ham's PC. Some suggested SCSI as an alternative.
I see the point, but in the end you do not want to share the bus you attach
your network controller to with devices like harddisks. So you end up having
an (expensive?) SCSI controller especially for packet.

The general opinion seems to be that it might be technically nice, but not
suitable for general use unless you have got a GPIB interface anyway. If
you own a PC running DOS, you might prefer an SCC-card and forget about
external controllers. If it doesn't run DOS, or it is not a PC, you are
stuck with serial TNCs (or a gateway DOS-PC) because you have a device
driver problem or hardware alternative.

Well, thanks to all who sent comments. There is no real need for a GPIB
TNC. Still, it's fun to build one :-).

Finally, from [e-mail] (Mike Bilow):

> As I recall, HP was asserting patent rights on the three-wire handshake
> used in IEEE-488?
> [..]
> I hope you are not the person assigned to collect the royalties!

No. My statements here are purely private comments and have no connection
whatsoever with HP's business interests.

73 de Jan, g0trr//dl5ue

--
 Jan Schiefer, g0trr, [e-mail], HP Labs Bristol, UK.  [phone]
Finally, I discovered a way to create lines longer then 80 columns, even on term

------------------------------

Date: Mon, 24 Jan 1994 11:00:02 -0800 (PST)
From: Jeff Brown <[e-mail]>
Subject: help understanding the division point of protocol vs app
To: [e-mail]

Well, after that interesting subject, here is what I am seeking help on in
english.

I am the director of the Vodem project, which is an effort to deliver
one-way internet news, email and FTP over cable TV, kinda like the
satellite feeds, but at a hardware cost of about $150, and the cheapest
monthly fee we can get from the carriers.  Anyway, the vodem system can
deliver a file or files one-way at over 90KBPS, but involves a proprietary
formt and protocol.

What I don;'t understand is where the protocols such as TCP/IP and UUCP
end and the applications or agents for processing news and mail begin.  In
other words, where do I interrupt a normal SLIP/PPP/UUCP "feed" so that I
can transmit the "feed" files over VODEM and have the individual user pick
up the processing of the "feed".  You can kind of think of the VODEM as a
Kermit or ZMODEM type of thing - just for file transfer.

Also, some help understanding how mail and news feeds are different over
UUCP and TCP/IP (SLIP, PPP) would be greatly appreciated.  I have searched
many texts but can't find anything to help me burn off the fog if
ignorance.  Thanks in advance for all of the wisdom I am about to receive
<grin>.


Jeff Brown on Speedway Free Access -- (10288)-1-503-520-2222
[e-mail]

------------------------------

Date: Tue, 25 Jan 94 04:35:00 -0000
From: [e-mail] (Mike Bilow)
Subject: help understanding the division point of protocol vs app
To: [e-mail]

Cc: [e-mail]

In a msg on <Jan 24 19:00>, Jeff Brown writes:

 JB> What I don;'t understand is where the protocols such as TCP/IP
 JB> and UUCP end and the applications or agents for processing
 JB> news and mail begin.  In other words, where do I interrupt a
 JB> normal SLIP/PPP/UUCP "feed" so that I can transmit the "feed"
 JB> files over VODEM and have the individual user pick up the
 JB> processing of the "feed".  You can kind of think of the
 JB> VODEM as a Kermit or ZMODEM type of thing - just for file
 JB> transfer.

 JB> Also, some help understanding how mail and news feeds are
 JB> different over UUCP and TCP/IP (SLIP, PPP) would be greatly
 JB> appreciated.  I have searched many texts but can't find
 JB> anything to help me burn off the fog if ignorance.  Thanks in
 JB> advance for all of the wisdom I am about to receive.

Oh my God...

I don't know where to begin.  Maybe something a little unusual, like
Padlipsky's "The Elements of Networking Style," might be helpful.  Padlipsky is
something of an in-your-face controversial iconoclast, but he writes well and
takes on this issue of how we divide things up.  He has an axe to grind, which
is that he hates the seven-layer model, but you don't even need to know that.

This seven-layer model is pretty useful whether you think it is a good model or
not, because it does give some ways of classifying the protocols.  At the
bottom layer, the "Physical Layer," you have protocols such as RS-232 and CCITT
V.35, which define how device plug in and transfer groups of bits at a time.
The next layer up, the "Link Layer," defines how two devices which are
physically connected can have a logical connection for meaningful data flow;
SLIP, PPP, UUCP-g, and Ethernet are all at this layer.

At the third layer from the bottom, you have the "Network Layer," which defines
how chains of devices communicating at the link layer can be strung together to
give the illusion of an end-to-end connection; IP is the Network Layer protocol
we play with here.  The fourth layer up, the "Transport Layer," provides some
way of moving more than individual blocks of raw data across the network, and
of attaching some kind of agreed upon functional interpretation to them; TCP,
UDP, ICMP, and their friends are all Transport Layer protocols.

This model is open to a lot of criticism, especially as you reach the higher
layers where it becomes very hard to define where the protocols separate.
These kinds of issues often degenerate into religious warfare, and a number of
protocols have been developed which do not fit neatly into this model.  (For
example, whether IP routing protocols live at the Network Layer or the
Transport Layer is always good for a fight.)

But the main principle here that no one would disagree with is the ultimate
modularity of the protocol layers.  Two hosts participating in an end-to-end
TCP connection have no need to know whether the data is being passed over SLIP
or Ethernet somewhere in the middle.  Very high level protocols, such as SMTP,
are supposed to be able to be designed only to interact directly with the
public interface of the protocol immediately below, such as TCP.  There are
usually dependencies in practice, as when a mail circuit gets passed over a
7-bit network and 8-bit characters have to be accounted for (or prohibited).
However, the design is such that SMTP need not be implemented differently over
Ethernet than over SLIP.

-- Mike

------------------------------

Date: Mon, 24 Jan 94 23:35 MET
From: [e-mail] (Fred Baumgarten)
Subject: ping-pong convers for Linux FTP site gone ?
To: [e-mail] (Advanced Amateur Radio Networking Group)

: Date: Mon, 24 Jan 94 08:09:58 CET
: From: BARRY TITMARSH <[e-mail]>
: To: Fred Baumgarten <[e-mail]>,

: Hi. Fred
: Question whats happend to 129.13.109.160 the ftp site for ping-pong convers
: is it closed ?  its been not reachable for some time. or the ftp server
: down.
: Is there any new ftp site on the internet for anonymous ftp of the
: ping-pong convers package. ?
: Thanks..
: Barry..

No the site is still up and running ! It's just your domainiazed name which
worries our security manager:

    your ip-addr -> hostname -> ip-addr != your ip-addr

I can't help you, set up name server entries corretly and it'll work fine
again !

73, Fred

PS: this conversd does _not_ work only in linux boxes... Comments welcome !
--
Fred Baumgarten    [44.130.29.10]

------------------------------

Date: Mon, 24 Jan 1994 07:37:17 CST6
From: "Chris Cox  W0/G4JEC" <[e-mail]>
Subject: TCP MSS and TCP WIN settings
To: [e-mail]

Jack, kf5mg wrote in a recent epistle:
> Any idea how to tell what Interface a TCP socket is going to be
> using?

> 73's  de  Jack  -  kf5mg

I don't see how you could tell.  The determination of how a packet is
routed is under the auspices of IP not TCP.  It is quite conceivable,
even on a radio circuit, that a packet (or rather stream of
characters) which is queued, but not acknowledged, could be resent by
a completely different path on each attempt at transmission.
Naturally you can extrapolate this over the course of a socket-pair's
life, and, therefore, you have no way of telling (except at some
given instant by peeking at the routing table) how your session will
be routed.

Chris
--
Chris

   Chris Cox  W0/G4JEC                     [e-mail]
   Network Analyst                                NIC Handle:   CC345
   North Memorial Medical Center                  Tel: [phone]
   3300 Oakdale Avenue North                      Fax: [phone]
   Robbinsdale, MN  55422

     ----- For mail of a more social nature, please use -----
           Internet: [e-mail]
           Amprnet:  [e-mail]

------------------------------

Date: Mon, 24 Jan 94 15:00:58 GMT
From: Alan Cox <[e-mail]>
Subject: TCP MSS and TCP WIN settings
To: [e-mail], [e-mail]

This issue has been discussed a lot on the Linux developer lists of late and
some suggestions were

1. Allow MTU/MSS settings per route for user configuration
2. Use 'Dont Fragment' and lower the mtu and resend on seeing such an error

Alan

------------------------------

Date: Mon, 24 Jan 94 19:04:23 GMT
From: Jan Schiefer <[e-mail]>
Subject: TNC3s information
To: [e-mail]

A number of people expressed their interest in the two TNC designs from
Germany. I found some info about one of them, I'll keep digging for the
other one. The following info is from the advert in the german ham magazine
cq/DL, 1/94.

- 15MHz 68302 processor in 16 bit mode
- 64KB RAM, expandable to 1MB
- real time clock
- modems are puggable modules, 1200bps AFSK and 9600bps FSK (G3RUH) are
  currently supported
- two modem ports can be used at the same time
- modem interface is capable of 1Mbps
- up to 115 kbps on the RS-232
- power supply 12V, 120mA (w/o modems)
- ROM-Software: Firmware (similar to WA8DED), KISS, system test
- software download to RAM possible
- integrated mailbox software
- connectors compatible to TNC2

I don't know whether they have distributors outside Germany, but it is
worth giving them a ring. This is a commercial product, but Ulf is a real
ham, so he should be open to weird&wonderful ideas.

SYMEK GmbH
Ulf Kumm, DK9SJ
Johannes-Kraemer-Strasse 34
D-70597 Stuttgart
Tel: [phone]
Fax: [phone]

German prices are DM490 for the CPU board in a nice box, DM75 for the 1200
and DM165 for the 9600 modem. RAM expansion to 256KB is DM40.

I have no connection to the business of SYMEK and this posting is totally
unrelated to my employer.

73 de Jan, g0trr//dl5ue

--
 Jan Schiefer, g0trr, [e-mail], HP Labs Bristol, UK.  [phone]
Finally, I discovered a way to create lines longer then 80 columns, even on term

------------------------------

Date: Mon, 24 Jan 94 10:13:09 mdt
From: [e-mail]
Subject: Unclear about MTU in attach...
To: [e-mail]

Perhaps something can be cleared up:

On this gateway, the ethernet MTU is 1500...  So, the TCP MSS, window,
etc. settings reflect that.

Since you can't set those things per-port, if someone on the air sets THEIR
station up similarly (with MTU of 1500) then TCP will negotiate an MTU of
1500.  (Any routers in the path are smart enough to accept a packet that
big...  not that it is encouraged to do that...)

Ok.  Since the MTU on the interface ATTACH command for the radio port is
256 bytes, what will actually happen?  Is it smart enough to fragment
the packet into small-enough pieces?

I know that if one were to set the ethernet MTU to, say, 576 (in its
attach command) but specify that it actually use 1500 byte packets, you
will soon be faced with thousands of Ibuffails and a probable crash...
Does a radio port behave the same way?  (at least, a KISS port?)

<Clint>

[e-mail]

------------------------------

End of TCP-Group Digest V94 #21
******************************